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BEST AVAILABLE COPY 

Verfahren zur Installation und Konf iguration 

von Softwarekomponenten 

Die vorliegende Erfindung betrifft ein Verfahren zur auto- 
5 matischen Installation und Konf iguration von Softwarekomponen- 
ten in einem Computernetzwerk, das eine Vielzahl von Benutzer- 
rechnern und zumindest eine Netzwerkressource von installierba- 
ren Softwarekomponenten umfaftt. Die Erfindung betrifft ferner 
Computerprogrammobjekte zur Durchfuhrung dieses Verfahrens in 
10 Form eines Regelpakets, eines Frameworks und eines Klientpro- 
gramms f sowie Computer und Datentrager, die mit solchen Pro- 
grammobjekten programmiert sind. 

Die Verteilung, Installation und Konf iguration von Soft- 
warekomponenten in grofieren Computernetzwerken, z.B. Fir- 
15 mennetzwerken mit Tausenden von unterschiedlichen Benutzerrech- 
nern, auf denen Hunderte von Softwarekomponenten laufen, die 
iiberdies teils unterschiedlich zu konf igurieren sind, ist in 
der Praxis ein nicht-triviales Problem. 

Zur Losung dieses Problems wurden bereits verschiedenste 
20 Mechanismen vorgeschlagen, siehe insbesondere: 

"Software Distributor Administration Guide for HP-UX Hi, 

Edition 3", Hewlett-Packard Company, Juni 2002, 

http : //docs . hp . com/hpux/pdf /B2355-90754 . pdf; 

Bailey, E. C: "Maximum RPM - Taking the Red Hat Package 
25 Manager to the Limit", Red Hat Software, Inc., Juni 1998, 

http: //www. rpm.org/local/maximum-rpm.ps . gz; 

Jackson, I., et al.: „Debian Packaging Manual, Version 

3.2.1.0*, 24. August 2000, 

http: //www. sylence.net/stuf f /DebianJPackaging_Manual .pdf ; 
30 sowie ferner: 

Franken, K. : "Using RPM-SuperVisor, vl.ll", 6. Nov. 2001, 
http: / /www. klaus . franken. de/rpmsv/download/rpmsv. pdf ; 
"Safe Mechanism for Installing Operation System Updates 
with Applications", IBM Technical Disclosure Bulletin, IBM 
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Corp. New York, US, Bd. 41, Nr. 1, 1998, Seiten 557-559, 
ISSN: 0018-8689; 

"Windows Installer Service Overview", Microsoft Corpora- 
tion, 1999, http: //download. microsoft . com/download/f /7/7/ 
5 f777da84-82d-4b90-a597-e329e09032b0ZWIS-Pro.doc. 

Bei alien bekannten Losungen wird die Installation der Soft- 
ware komponent en auf den Benutzerrechnern stets von einer zen- 
tralen Netzwerkressource aus initiiert. Dazu werden im einfach- 
sten Fall die Software komponent en, eventuell gemeinsam mit zu- 

10 geordneten Regelpaketen, die Anweisungen zur Installation der 
jeweiligen Sof twarekomponente (n) enthalten, an die Benutzer- 
rechner versandt (zentrale Sof tware-„Push"-Verteilung) , was ho- 
he Netzwerkbandbreiten belegt, selbst wenn einzelne Software- 
komponenten auf bestimmten Benutzerrechnern gar nicht erforder- 

15 lich sind. Verbesserte Losungen verteilen in einem ersten 
Schritt Aktualisierungslisten mit Verweisen auf von der zentra- 
len Netzwerkressource abzuholende Sof t ware komponent en an die 
Benutzerrechner oder stellen solche Listen zur Abholung bereit 
(zentrale Aktualisierungslisten-„Push v> - oder -„Pull"-Vertei- 

20 lung); die Sof twarekomponenten werden dann wieder - eventuell 
gemeinsam mit oder integriert in Regelpakete zu ihrer Installa- 
tion - an die Benutzerrechner versandt. 

Beide bekannten Systeme haben entscheidende Nachteile. Im 
ersten Fall ist eine genaue Kenntnis der Ausstattung und Anfor- 

25 derungsprofile aller Benutzerrechner im Feld erf orderlich, was 
den Aufbau und die Verwaltung umf angreicher Verzeichnisse und 
Verteilungsschliissel bedeutet. Auch im zweiten Fall liegt wei- 
terhin eine zentrale Verteilungsstrategie vor, die nicht auf 
rasche Vor-Ort-Veranderungen der Hard- oder Sof twareausstattung 

30 der Benutzerrechner reagieren kann, wie das AnschlieJien neuer 
Hardware, das Anmelden in einem Netzwerk, das Anmelden eines 
Benutzers usw., welche unter Umstanden nicht nur Neuinstalla- 
tionen, sondern auch Neu- und Umkonf igurationen von Software- 
komponenten notwendig machen konnen. 
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Die Erfindung beruht auf der Erkenntnis, dafi es wunschens- 
wert ware, eine Losung zur Installation und Konf iguration von 
Softwarekomponenten in einem Computernetzwerk aus vielen unter- 
schiedlichen Benutzerrechnern zu schaffen, welche auf individu- 
elle Anforderungen und aktuelle Zustandsanderungen jedes ein- 
zelnen Benutzerrechners vollautomatisch eingehen und reagieren 
kann . 

Dieses Ziel wird in einem ersten Aspekt mit einem Verfah- 
ren der einleitend genannten Art erreicht, das sich gemaft der 
Erfindung auszeichnet durch die Schritte: 

a) Bereitstellen eines Frameworks auf der Netzwerkres- 
source, welches ein Regelpaket fur jede der installierbaren 
Softwarekomponenten der Netzwerkressource und eine Liste abzu- 
arbeitender Regelpakete umfafit, nicht jedoch die Softwarekompo- 
nenten selbst, 

wobei zumindest eines der Regelpakete eine Routine zum La- 
den seiner Sof twarekomponente von der Netzwerkressource her und 
Installieren auf einem Benutzerrechner und zumindest dieses 
Oder eines der anderen Regelpakete eine Routine zum Kon- 
figurieren seiner auf einem Benutzerrechner installierten Soft- 
warekomponente umfafit, 

b) Obertragen des gesamten Frameworks an einen Benutzer- 
rechner; und 

c) Abarbeiten der Liste abzuarbeitender Regelpakete mit 
Installationsroutinen auf dem Benutzerrechner unter Aufrufen 
ihrer Installationsroutinen und nochmaliges Abarbeiten der Li- 
ste abzuarbeitender Regelpakete mit Konf igurationsroutinen auf 
dem Benutzerrechner unter Aufrufen ihrer Konf igurationsrouti- 
nen, 

wobei zumindest Schritt c) durch ein lokales Ereignis auf 
dem jeweiligen Benutzerrechner ausgelost wird, bevorzugt durch 
einen Systemstart oder -stop, ein Systemsperren oder 
-freigeben, eine Benutzeran- oder -abmeldung, eine Netzwerkan- 
oder -abmeldung, einen Programmstart oder -ende, das An- oder 
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Abschlieflen einer Hardwareausstattung oder durch einen Zeitge- 
ber . 

Auf diese Weise wird erstmals eine vollautomatisierte, de- 
zentrale und dynamische Selbstinstallation und -konf iguration 
5 jedes einzelnen Benutzerrechners moglich, welche rasch auf lo- 
kale Ereignisse reagieren kann. Da jeder Benutzerrechner stets 
uber das gesamte Framework mit alien potentiell notwendigen Re- 
gelpaketen verfugt, konnen lokale Ereignisse und Zustandsande- 
rungen des Benutzerrechners unmittelbar in entsprechende Soft- 

10 warekomponenten-Installationen oder -Konf igurationen umgesetzt 
werden, wobei jeder Benutzerrechner grofttnioglich autark ist. 

Mit dem Verfahren der Erfindung ist erstmals nicht nur die 
Verteilung und die Installation von Sof twarekomponenten mog- 
lich, sondern gleichzeitig auch ihre Konf iguration, d.h. die 

15 Einstellung spezieller Parameter der installierten Softwarekom- 
ponente. Damit konnen z.B. benutzerspezif ische, anwendungsumge- 
bungsspezif ische, gruppenspezif ische oder aber auch einfach nur 
f irmeneinheitliche Konf igurationen auf alien Benutzerrechnern 
im Netzwerk durchgefuhrt werden. Alles, was dazu erforderlich 

20 ist, ist die einmalige Definition eines Regelpakets fur die je- 
weilige Sof twarekomponente . 

Dabei wurde erstmals auch das Problem erkannt und beruck- 
sichtigt f dafi eine korrekte Konf iguration der einzelnen Soft- 
warekomponenten erst nach Abschluft der Installation aller Soft- 

25 warekomponenten moglich ist, da Installationsvorgange haufig 
die Nebenwirkung eines Uberschreibens der Konf iguration tiefer- 
liegender Sof twarekomponenten haben. Dadurch, daii in einem er- 
sten Durchgang zunachst alle Installationsroutinen und erst an- 
schlieBend in einem zweiten Durchgang alle Konf igurationsrouti- 

30 nen abgearbeitet werden, ist eine korrekte Konf iguration aller 
Sof twarekomponenten gewahrleistet . 

Eine besonders bevorzugte Ausf iihrungsf orm des erfindungs- 
gemaften Verfahrens, bei welchem die erfolgreiche Installation 
einer Sof twarekomponente auf einem Benutzerrechner die An- oder 

35 Abwesenheit, Konf iguration oder Dekonf iguration einer anderen 
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Sof twarekomponente als Voraussetzung haben kann, zeichnet sich 
dadurch aus, 

dafi im Schritt a) das Framework einen Detektor fiir jede 
mogliche Voraussetzung und zumindest eines der Regelpakete eine 
5 Routine zum Deinstallieren seiner Sof twarekomponente von einem 
Benutzerrechner und zumindest dieses oder eines der anderen Re- 
gelpakete eine Routine zum Riickgangigmachen (Dekonf igurieren) 
der Konf iguration seiner Sof twarekomponente auf einem Benutzer-- 
rechner umfaftt, und 

10 dafi im Schritt c) , wenn im Zuge eines Regelpakets mittels 

eines Detektors festgestellt wird, daft die An- oder Abwesen- 
heit, Konf iguration oder Dekonf iguration einer anderen Soft- 
warekomponente erforderlich ist, die Installations-, Deinstal- 
lationsroutine, Konf igurat ions- oder Dekonf igurationsroutine 

15 des dieser anderen Sof twarekomponente zugeordneten Regelpakets 
aufgerufen wird. 

Auf diese Weise werden autarke Regelpakete geschaffen, 
welche ausschlieftlich iiber ihre gegenseitigen Abhangigkeiten 
referenziert sind. Dazu stellt das Framework wiederverwendbare 

20 Detektoren zur Verfiigung, mit deren Hilfe die Voraussetzungen 
fur die Installation oder Konf iguration einer Sof twarekomponen- 
te auf dem Benutzerrechner rasch iiberpruft werden konnen. Dies 
erleichtert einerseits die Definition der Regelpakete fiir die 
Bereitstellung des Frameworks, andererseits brauchen die Regel- 

25 pakete auf dem Benutzerrechner nur eines nach dem anderen abge- 
arbeitet zu werden, wobei sie sich entsprechend ihrer Abhangig- 
keiten auch gegenseitig aufrufen konnen. Jedes Regelpaket 
„weifi" selbst, wie es seine zugeordnete Sof twarekomponente in- 
stallieren, deinstallieren, konf igurieren bzw. dekonf igurieren 

30 kann. Das Erzeugen von speziellen Installations- oder Konfigu- 
rations-Scripts fiir die einzelnen Benutzerrechner entfallt. 

Eine weitere bevorzugte Ausf iihrungsf orm des Verfahrens der 
Erfindung zeichnet sich dadurch aus, daft das Framework auch De- 
tektoren fiir die Hardware- oder Betriebssystemausstattung eines 

35 Benutzerrechners umfalit und im Zuge einer Routine mittels eines 
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solchen Detektors iiberprttft wird, ob der Benutzerrechner fur 
die jeweilige Installation, Deinstallation, Konf iguration oder 
Dekonf iguration der Sof twarekomponente geeignet ist, und/oder 
daft im Zuge einer Routine vorab gepruft wird, ob die jeweilige 
5 Installation, Deinstallation, Konf iguration oder Dekonfigura- 
tion der Softwarekomponente auf dem Benutzerrechner bereits er- 
folgt ist und, wenn ja, die Routine sofort beendet wird. 

Dadurch wird jedes Regelpaket noch starker autark, d.h. es 
„weift" auch, ob es fur den jeweiligen Benutzerrechner zustandig 
10 bzw. anzuwenden ist. Die Abarbeitung der Regelpaket e auf den 
Benutzerrechnern wird dadurch noch einfacher. Im allgemeinsten 
Fall konnen z.B. einfach alle im Framework vorhandenen Regelpa- 
kete abgearbeitet werden, beginnend mit dem ersten, und jedes 
Regelpaket entscheidet fur sich, ob es iiberhaupt auszufuhren 
15 ist, andere, vorauszusetzende Regelpakete aufrufen soil usw. 

Bevorzugt konnen Schritt b) und/oder Schritt c) auch durch 
ein entferntes Ereignis auf der Netzwerkressource ausgelost 
werden, z.B. das Aussenden einer Gruppen- oder Broadcastnach- 
richt usw. , wodurch auch das Verhalten herkommlicher zentraler 
20 Verteilungsverf ahren mit dem erf indungsgemafien Verfahren nach- 
gebildet werden kann. 

Die Erfindung erstreckt sich auch auf ein Computerpro- 
gramm, welches das erf indungsgemafie Verfahren implementiert . 

Ein weiterer Aspekt der Erfindung besteht in der Schaffung 
25 eines Regelpakets, das auf einem Betriebssystem eines Benutzer- 
rechners ausfuhrbar ist, wie in den Anspruchen 7 bis 12 defi- 
niert. Beziiglich der Merkmale und Vorteile des erf indungsgema- 
fien Regelpakets wird auf die obigen Ausfuhrungen zum Verfahren 
verwiesen. 

30 Eine bevorzugte Ausf uhrungsf orm eines Regelpakets der Er- 

findung zeichnet sich dadurch aus, dafi es mindestens einen Aus- 
loseverweis auf ein lokales Ereignis auf dem Benutzerrechner 
oder ein entferntes Ereignis auf der Netzwerkressource enthalt, 
wobei der Ausloseverweis diesem Ereignis zumindest eine der 

35 Routinen des Regelpakets zuordnet. Dadurch konnen auch einzelne 
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Regelpakete bzw. deren Routinen ereignisgesteuert ausgefuhrt 
werden, was die Flexibilitat und Reaktionsf ahigkeit des Systems 
wesentlich erhoht. 

In der Praxis kommen standig neue Sof twarekomponenten auf 
5 den Markt . Wenn keine besonderen MaiSnahmen ergriffen werden, 
wurde die Anzahl der Regelpakete im Framework standig anwach- 
sen; andererseits werden Regelpakete im Framework obsolet, z.B. 
wenn Sof twarekomponenten aufter Dienst gestellt werden. Solche 
obsoleten Regelpakete werden zweckmafligerweise aus dem Frame- 

10 work entfernt, auf einzelnen Benutzerrechnern konnen sie jedoch 
noch erforderlich sein, beispielsweise wegen veralteter Hard- 
warekomponenten. Es ist daher besonders gunstig, wenn Regelpa- 
kete auch in einen inaktiven Zustand versetzbar sind, in wel- 
chem nur ihre Deinstallationsroutine aufrufbar ist. Dadurch 

15 kann die Installation veralteter Sof twarekomponenten verhindert 
werden, ihre Deinstallation ist aber jederzeit moglich. 

Die Erfindung erstreckt sich auch auf einen Computer, der 
mit zumindest einem erf indungsgemaften Regelpaket programmiert 
ist . 

20 Ein weiterer Aspekt der Erfindung ist ein Framework, das 

auf einer Netzwerkressource in einem Computernetzwerk fur eine 
Vielzahl von Benutzerrechnern bereitstellbar ist, wie in den 
Anspruchen 14 und 15 definiert, und das erf indungsgemafie Regel- 
pakete enth£lt. Bezuglich der Merkmale und Vorteile des Frame- 

25 works wird auf die obigen Ausfiihrungen zum Verfahren verwiesen. 

Die Erfindung erstreckt sich auch auf einen Computer und 
einen maschinenlesbaren Datentrager, die mit einem erfindungs- 
gemalien Framework programmiert sind. 

Noch ein weiterer Aspekt der Erfindung besteht in der 

30 Schaffung eines Klientprogramms, das auf einem Benutzerrechner 
ausfuhrbar ist, wie in den Anspruchen 18 bis 23 definiert, und 
ein Framework gemafi der Erfindung enthalt. Bezuglich weiterer 
Merkmale und Vorteile des Klientprogramms wird auf die obigen 
Ausfiihrungen zum Verfahren verwiesen. 
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Gemaft einer bevorzugten Ausf iihrungsf orm weist das Klient- 
prograitun eine lokale Datenbank auf, welche eine Liste von Re- 
gelpaketen mit * erf olgreich durchlauf enen Installationsroutinen 
und eine Liste von Regelpaketen mit erfolgreich durchlauf enen 
5 Konf igurationsroutinen enthalt. Mit Hilfe dieser Datenbank kann 
die Abarbeitung der Regelpakete beschleunigt werden, da bei- 
spielsweise fur bereits installierte oder konf igurierte Sof t- 
warepakete der Aufruf der entsprechenden Regelpakete unterblei- 
ben kann. 

10 Oberdies eroffnet dies die Moglichkeit, dafi das Klientpro- 

gramm die in den Listen eingetragenen Regelpakete mit den im 
Framework enthaltenen Regelpaketen vergleicht und fur jene Re- 
gelpakete, welche im Framework nicht aufscheinen, in einem er- 
sten Durchgang deren Dekonf igurationsroutinen und in einem 

15 zweiten Durchgang deren Deinstallationsroutinen abarbeitet, wo- 
durch obsolete oder veraltete Softwarekomponenten automatisch 
entfernt werden konnen. 

Gemaft einer bevorzugten Ausf iihrungsf orm eines Klientpro- 
gramms, welches von Regelpaketen mit Ausloseverweisen zur er- 

20 eignisgesteuerten Ausflihrung Gebrauch macht, uberwacht das 
Klientprogramm das Auftreten eines lokalen Ereignisses auf dem 
Benutzerrechner, besonders bevorzugt eines Systemstarts oder 
-stops f eines Systemsperrens oder — f reigebens, einer Benutze- 
ran- oder -abmeldung, einer Netzwerkan- oder -abmeldung, eines 

25 Programmstarts oder -endes, des An- oder AbschlieJJens einer 
Hardwareausstattung f oder des Ansprechens eines Zeitgebers, 
und/oder das Auftreten eines entfernten Ereignisses auf der 
Netzwerkressource, besonders bevorzugt das Aussenden einer 
Gruppen- oder Broadcastnachricht , und ruft die diesem Ereignis 

30 tiber den Ausloseverweis zugeordnete Routine des entsprechenden 
Regelpakets auf. Dies kann zweckmafiigerweise auch mit Hilfe der 
Listen in der Datenbank erfolgen, in welche die Ausloseverweise 
der Regelpakete miteingetragen werden konnen. Auf diese Weise 
konnen auch einzelne oder Gruppen von Regelpaketen bzw. deren 

35 Routinen ereignisgesteuert ausgeflihrt werden. 
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In jedem Fall ist es besonders giinstig, wenn das Klient- 
programm ein Transaktionssystem fur jede systemmodif izierende 
Komponente, insbesondere fur die Regelpakete, aufweist. Dadurch 
kann jederzeit ein Rollback des Systems vorgenommen werden, 
5 wenn z.B. eine Installation oder Konf iguration fehlschlagt, wie 
in der Technik bekannt. Die Betriebssicherheit des Klientpro- 
gramms wird dadurch wesentlich erhoht . 

Schlieftlich erstreckt sich die Erfindung auch auf einen 
Computer, der mit einem erf indungsgemafien Klientprogramm pro- 
10 grammiert ist. 

Die Erfindung wird nachstehend anhand von in den Zeichnun- 
gen dargestellten Ausf iihrungsbeispielen naher erlautert. In den 
Zeichnungen zeigt : 

Fig. 1 ein Blockschaltbild eines Computernetzwerkes, in 
15 welchem das Verfahren, die Programmob jekte und Computer der Er- 
findung zur Anwendung gelangen, 

Fig. 2 ein Blockschaltbild eines beispielhaf ten, mit einem 
Klientprogramm programmierten Benutzerrechners der Erfindung, 

Fig. 3 den schematischen Aufbau eines Frameworks der Er- 
20 findung, 

Fig. 4 den schematischen Aufbau eines Regelpakets der Er- 
findung, 

Fig. 5 die gegenseitigen Beziehungen mehrerer beispielhaf- 
ter Regelpakete in Form eines Beziehungsdiagramms, 
25 Fig. 6 ein Fluftdiagramm des Verfahrens der Erfindung, 

Fig. 7 ein Beispiel fur die von einer Installationsroutine 
erzeugten Eintrage in der lokalen Datenbank, 

Fig. 8 ein Beispiel fiir die von einer Konf igurationsrou- 
tine erzeugten Eintrage in der lokalen Datenbank, 
30 Fig. 9 mehrere mogliche Auslosearten fur die auf dem Be- 

nutzerrechner ablaufenden Schritte des Verfahrens der Erfindung 
in Form eines Flufidiagramms, und 

Fig. 10 das Blockschaltbild einer moglichen Implementie- 
rung des Klientprogramms auf einem Betriebssystem mit voneinan- 
35 der isolierten Ausf iihrungsschichten. 
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Fig. 1 zeigt ein Computernetzwerk 1, das eine Vielzahl von 
Benutzerrechnern 2 umfafit. Ein beispielhaf ter Benutzerrechner 2 
ist in Fig. 2 ausfuhrlicher gezeigt und enthalt eine Anzahl von 
schematisch dargestellten Softwarekomponenten BS1, A, B, . . , 
5 welche je nach Einsatzgebiet des Benutzerrechners 2 rechner-, 
benutzer- oder anwendungsspezif isch installiert und konfigu- 
riert werden sollen. 

Die Gesamtheit aller auf dem Benutzerrechner 2 potentiell 
installier- und konf igurierbarer Sof twarekomponenten ist in 

10 Fig. 2 mit SW bezeichnet. Dabei ist zu beachten, da/3 die In- 
stallation und Konf iguration der Sof twarekomponenten SW komple- 
xen gegenseitigen Abhangigkeiten unterworfen sein kann. Bei- 
spielsweise erfordert die Installation der Sof twarekomponente B 
eine vorherige Installation der Sof twarekomponente A und diese 

15 wiederum eine vorherige Installation der Sof twarekomponente 
BS1, welche z.B. bereits auf dem Benutzerrechner 2 installiert 
sein kann, weil sie Teil des Betriebssystems ist. Andererseits 
kann es Sof twarekomponenten geben, welche unbedingt die Abwe- 
senheit, d.h. Deinstallation, einer anderen Softwarekomponenten 

20 fur ihre korrekte Installation voraussetzen. Eine solche Situa- 
tion ist in Fig. 5 dargestellt (welche spater noch ausfiihrli- 
cher erortert wird) , wobei die mit „restrict" bezeichneten Pf a- 
de zwischen Softwarekomponenten die Vorausset zung der Abwe- 
senheit einer Sof twarekomponente angeben, jene mit „require xv 

25 bezeichneten Pfade die Voraussetzung der Anwesenheit einer 
Sof twarekomponente . 

Es versteht sich, dafi der Begriff ,,Sof twarekomponente", 
wie er hier verwendet wird, je nach Anwendungsf all und Erfor- 
dernis jede Art von Granularitat bzw. „Korngrofle" von Software 

30 umfaBt, sei es ein Treiber, ein Unterprogramm, ein Programmob- 
jekt, ein Hauptprogramm, eine Unter- oder Hauptklasse, eine An- 
wendung, oder ein Anwendungskomplex . Darin zeigt sich die Mach- 
tigkeit der hier vorgestellten Losung: So kann z.B. ein Regel- 
paket RPi fur die allgemein bekannte Sof twarekomponente „Micro- 

35 soft Office XP mit Microsoft Frontpage, ohne Netzwerkunterstut- 
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zung" definiert werden, gleichzeitig ein weiteres Regelpaket 
RP2 fur die - sich teilweise uberlappende, teilweise unterfal- 
lende - Sof twarekomponente ^Microsoft Frontpage, mit Netzwerk- 
unterstiitzung" . 

5 Zuruckkehrend auf Fig. 1 wird das gesamte Beziehungssystem 

aller potentiell auf den Benutzerrechnern 2 installierbaren 
Softwarekomponenten SW in Form eines Frameworks FW abgebildet, 
dessen struktureller Aufbau spater noch ausf uhrlicher unter Be- 
zugnahme auf die Fig. 3 und 4 eriautert wird. Das Framework FW 
10 wird im Computernetzwerk 1 auf einer Netzwerkressource RESi be- 
reitgestellt . 

Unabhangig von dem Framework FW werden im Computernetzwerk 
1 auf einer weiteren Netzwerkressource RES 2 alle potentiell in- 
stallierbaren Softwarekomponenten SW (BS1, A, B, . . ) bereitge- 
15 stellt. 

Es versteht sich, daii die Netzwerkressourcen RESi und RES 2 
auch ein und dieselbe Netzwerkressource RES sein konnen (siehe 
z.B. Fig. 2) oder ihrerseits in geographisch verteilte Netz- 
werkressourcen aufgeteilt werden konnen (siehe z.B. die Vertei- 

20 lung der Softwarekomponenten A und B auf die Netzwerkressourcen 
RES 2 und RES 3 in Fig. 2) . Auch ist es moglich, dali eine der 
Netzwerkressourcen, insbesondere jene fiir die Softwarekomponen- 
ten, tatsachlich ein „of f line"-Datentrager ist, z.B. eine CD- 
Rom usw., wie in Fig. 2 beispielhaft fiir die Sof twarekomponente 

25 B angedeutet. 

Der Aufbau und die Pflege des Frameworks FW, d.h. das Ein- 
speisen in die Netzwerkressource RESi, werden an Administrator- 
arbeitsplatzen 3 durchgeftihrt . Die Verteilung bzw. Ausbreitung 
des Frameworks FW im Computernetzwerk 1 bis zu den Benutzer- 

30 rechnern 2 kann auf jede beliebige Art erfolgen, beispielsweise 
durch Push-Technologien, wie Broadcast- oder Gruppennachrichten 
nach dem Internetprotokoll, oder Pull-Technologien, wie Abholen 
durch die Benutzerrechner 2 von Logon-Shares auf den Netzwerk- 
ressourcen bei einem Systemstart oder einer Benutzeranmeldung, 
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durch Peer-to-Peer-Propagierungs- oder Replizierungsverf ahren 
usw. 

Beispielsweise kann das Framework FW in der Art von Inter- 
net-Domain-Name-Services von Netzwerkknoten, wie der Netzwerk- 
5 ressource RESi, zu Netzwerkknoten, wie der Netzwerkressource 
RES 2 , mittels Spiegelung repliziert und damit verteilt werden. 
Dadurch kann das Framework FW auch auf Netzwerkressourcen RES 2 
verfiigbar sein, welche fur die Bereithaltung von Sof twarekompo- 
nenten SW dienen, oder auch direkt von Benutzerrechner 2 zu Be- 

10 nutzerrechner 2 („Peer-to-Peer") repliziert werden. Urn den 
Netzwerkverkehr bei der Verteilung des Frameworks FW moglichst 
gering zu halten, kann auch vorgesehen werden, daft nach einer 
erstmaligen Verteilung des gesamten Frameworks FW nur mehr Dif- 
ferenz-Updates des Frameworks FW auf seine jeweils aktuellste 

15 Version verteilt werden. 

Die weitere Beschreibung der Erfindung geht von einem Zu- 
stand aus, in welchem das Framework FW dem stellvertretend be- 
schriebenen Benutzerrechner 2 zur Verfugung steht. 

Der Aufbau des Frameworks FW wird anhand der Fig. 3 und 4 

20 naher erlautert. Gemafi Fig. 3 umfaftt das Framework FW einen 
Satz von Regelpaketen RP, und zwar ein Regelpaket RP fur jede 
potentiell auf einem Benutzerrechner 2 installier- und/oder 
konf igurierbare Sof twarekomponente BS1, A, B, . . Jedes Regelpa- 
ket RP bildet die Hard- und Sof twarevorausset zungen jeweils ei- 

25 ner Sof twarekomponente ab. 

Fig. 4 zeigt den Aufbau eines beispielhaf ten Regelpakets 
RP A fur die Sof twarekomponente A. Das Regelpaket RP A enthalt 
einen Verweis RES a auf seine zugeordnete Sof twarekomponente A, 
beispielsweise in Form eines Zeigers auf jene Netzwerkressource 

30 RES 2/ auf welcher die Sof twarekomponente A verfiigbar ist. 

Gemali Fig. 4 umfaftt jedes Regelpaket RP eine Routine 
„INST() M 4 zum Installieren der ihm zugeordneten Sof twarekompo- 
nente (hier: A) auf dem Benutzerrechner 2, eine weitere Routine 
„DEINST ( ) " 4' zum Deinstallieren diese Sof twarekomponente vom 

35 Benutzerrechner 2, eine Routine ^CONFIGO^ 5 zum Konf igurieren 
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dieser Sof twarekomponente und eine Routine „DECONFIG ( ) xx 5' zum 
Ruckgangigmachen („Dekonf igurieren >N ) der Konf iguration dieser 
Sof twarekomponente . 

Ein Regelpaket RP muB nicht alle vier Routinen 4, 4' , 5, 
5 5' enthalten, jedoch mindestens eine der Routinen 4, 4', 5, 5'. 
Bevorzugt enthalt das Regelpaket RP mindestens ein komplementa- 
res Routinenpaar 4/4' oder 5/5', so dafi zu der Installations- 
bzw. Konf igurationsroutine 4, 5 jeweils zumindest die zugeord- 
nete Deinstallations- bzw. Dekonf igurationsroutine 4' , 5' ent- 

10 halten ist. 

Es versteht sich, dafl die vier Routinen 4, 4' , 5 und 5' - 
soferne sie gemeinsame Codeabschnitte besitzen - auch strecken- 
weise in einer gemeinsamen Routine zusammengef aftt sein konnen, 
z.B. in einer gemeinsam zu durchlauf enden Einleitungsroutine 

15 des Regelpakets RP, oder uberhaupt durch einen gemeinsamen Co- 
deabschnitt implementiert werden konnen, welcher durch entspre- 
chende Auf ruf schalter gesteuert einmal z.B. die Funktion der 
Installationsroutine 4, ein anderes Mai z.B. die Funktion der 
Dekonf igurationsroutine 5' einnimmt, usw. In diesem Sinne sind 

20 die Routinen 4, 4', 5, 5' „f unktionelle" Routinen, nicht not- 
wendigerweise Routinen im programmtechnischen Sinne, wie fur 
den Fachmann ersichtlich. 

In der vorliegenden Beschreibung wird der Begriff „Instal- 
lieren^ zum grundsatzlichen Bereitstellen der Nutzungsmoglich- 

25 keit einer Sof twarekomponente auf einem Benutzerrechner verwen- 
det. Die Installation umfafit in der Regel das Speichern der 
Sof twarekomponente A auf einem lokalen Datenspeicher (z.B. der 
Festplatte) des Benut zerrechners, sowie haufig auch ein erstes, 
allgemeines Konf igurieren (siehe unten) der Sof twarekomponente, 

30 damit diese grundsatzlich betriebsf ahig ist. Zusatzlich kann 
die Installation auch eine oder mehrere Regeln fur das automa- 
tische Erganzen oder Verandern der gespeicherten Sof twarekompo- 
nente A mittels bereitgestellter Updates enthalten. 
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Der Begriff „Deinstallieren" wird fttr das Entfernen der 
Softwarekomponente SW vom Benutzerrechner 2, z.B. durch Loschen 
von der Festplatte, verwendet. 

Der Begriff „Konf igurieren" wird wiederum fur jede Form 
5 von einheitlicher , gruppenspezif ischer, benutzerspezif ischer 
oder anwendungssituationsspezif ischer Einstellung einer Soft- 
warekomponente verwendet, wie durch den Einstellungspf eil in 
Fig. 2 versinnbildlicht . Damit ermoglicht das erf indungsgemafte 
Verfahren nicht nur die autarke Installation aller erforderli- 

10 chen Sof twarekomponenten auf einem Benutzerrechner, sondern 
auch die Einstellung eines bestimmten, im Framework FW defi- 
nierten Zustandes dieser Sof twarekomponenten . 

Unter dem Begriff „Ruckgangigmachen einer Konf iguration" 
bzw. „Dekonf igurieren" wird in der vorliegenden Beschreibung 

15 das Wiederherstellen jener Einstellung einer Softwarekomponente 
verstanden, wie sie vor dem Konf igurieren geherrscht hat, 
und/oder das Einstellen der nach einer Deinstallation dieser 
Softwarekomponente verbliebenen anderen Sof twarekomponenten in 
der Art, wie es fur den aktuellen Systemzustand ohne die dein- 

20 stallierte Softwarekomponente erforderlich ist; letzteres ist 
auch mit dem Begriff Riickgangigmachen der Konf iguration „hin- 
sichtlich" dieser Softwarekomponente gemeint. 

GemaJi Fig. 4 kann das Regelpaket RP A optional einen oder 
mehrere Ausloseverweise TRIG A auf ein lokales oder entferntes 

25 Ereignis enthalten, bei dessen Auftreten zumindest eine seiner 
Routinen 4, 4', 5, 5' ausgefiihrt werden soil, wie spater noch 
anhand von Fig. 9 ausf uhrlicher erortert wird. 

Ferner kann das Regelpaket RP A auch lokale Ressourcen 
RES 4 , RES 5 fur z.B. kleine Sof twarekomponenten oder Konfigura- 

30 tionsparameter umfassen. 

Jede der Routinen 4, 4 r , 5, 5' enthalt eine eigenstandige 
Oberprufung der Voraussetzungen fiir die Installation, Konfigu- 
ration, Deinstallation oder Dekonf iguration der dem Regelpaket 
zugeordneten Softwarekomponente, beispielsweise das Erfordernis 

35 der Anwesenheit einer anderen Softwarekomponente („reguire"- 
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Pfade in Fig. 5) oder der Abwesenheit einer Komponente („re- 
strict^-Pf ade in Fig. 5) . Wenn die jeweilige Routine ein Anwe- 
senheitserfordernis („require") feststellt, ruft sie die In- 
stallationsroutine 4 des dieser anderen Sof tware komponente zu- 
5 geordneten anderen Regelpakets RP auf; wenn sie ein Abwesen- 
heitserfordernis (^restrict ") feststellt, dessen Deinstallati- 
onsroutine 4' . Auf diese Weise wird durch Abarbeiten der Regel- 
pakete das Beziehungsgef lecht von Fig. 5 eingehalten und ausge- 
fuhrt. Es ist klar, dafi diese Oberpriifung auch in einen den 
10 Routinen gemeinsamen Teil des Regelpakets ausgelagert sein 
kann, welcher bei Ausfuhrung einer Routine stets durchlaufen 
wird. 

Urn die Uberpriifung der An- oder Abwesenheit einer bestimm- 
ten Sof tware komponente zu vereinf achen, umfaftt das Framework FW 

15 einen Satz von Detektionsroutinen bzw. Detektoren DET f z.B. ei- 
nen Detektor DET A fur das Vorhandensein der Sof tware komponente 
A, einen Detektor DET BS i fur das Vorhandensein der Betriebssy- 
stemkomponente BS1 oder einen Detektor DEThw fur das Vorhanden- 
sein einer bestimmten Hardwareausstattung des bestimmten Benut- 

20 zerrechners 2, siehe Fig. 5. 

Die Detektoren DET konnen nicht nur die An- oder Abwesen- 
heit einer Sof twarekomponente SW uberpriifen, sondern auch ob 
eine Sof twarekomponente gerade lauft bzw. ausgefuhrt wird oder 
nicht. Alle diese Varianten werden in der vorliegenden Be- 

25 schreibung unter dem Begriff „An- oder Abwesenheit" zusammenge- 
fafit bzw. sind eine der moglichen Voraussetzungen fur eine 
Sof twarekomponente, die ein Detektor DET uberpriifen kann. 

Die Detektoren DET konnen sich auch gegenseitig aufrufen 
bzw. voneinander Gebrauch machen, z.B. wenn eine zu uberprti- 

30 fende Voraussetzung in mehrere einzelne Voraussetzungen zerleg- 
bar ist, fur welche bereits andere Detektoren vorhanden sind. 

Anlage 1 zeigt ein Implementierungsbeispiel fur einen De- 
tektor zur Feststellung der Anwesenheit der Sof twarekomponente 
„Microsoft Word 10.0" der Firma Microsoft. Die Subroutine „que- 
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ry_exist" uberpruft die Anwesenheit der Sof twarekomponente; die 
Subroutine „query_active NX , ob die Sof twarekomponente lauft. 

Jede der Routinen 4, 4', 5, 5' kann vorteilhaf terweise so 
gestaltet werden, dafi sie selbst bzw. mittels entsprechender 
5 Detektoren DET uberpruft, ob sie fur die auf dem Benutzerrech- 
ner 2 vorgefundene Hardware- oder Softwareausstattung geeignet 
ist und, wenn nicht, beispielsweise ohne weitere Aktion beendet 
wird, d.h. die Steuerung zuriickgibt. Auch kann die Routine 
uberpriifen, ob die aufgerufene Installation, Deinstallation, 

10 Konf iguration oder Dekonf iguration ihrer Sof twarekomponente 
nicht ohnehin bereits erfolgt ist, in welchem Fall sie eben- 
falls beendet wird, d.h. die Steuerung zuruckgibt. Alternativ 
konnten diese Priifungen aber auch in einen den Routinen gemein- 
samen Codeabschnitt (siehe oben) des Regelpakets RP oder in den 

15 aufrufenden Prozefl P (siehe unten) verlagert sein. 

Schliefilich umfaftt das Framework FW eine Liste L jener Re- 
gelpakete RP, mit deren Abarbeitung im Benutzerrechner 2 begon- 
nen werden soil. Es versteht sich, daft die Liste L z.B. nur auf 
das erste Regelpaket RP verweisen kann, welches in weitere Re- 

20 gelpakete RP rekursiert, oder einfach alle Regelpakete RP an- 
fuhrt, wenn diese jeweils fur sich die Voraussetzungen fur ihre 
Ausfuhrung feststellen, oder aber nur solche Regelpakete an- 
fuhrt, die von einem Administrator als „Tagespensum" vorgegeben 
werden usw. 

25 In einer bevorzugten Implementierung besteht ein Regelpa- 

ket RP aus einem Satz von Dateien, die durch eine zentrale Re- 
gelpaket-Spezif izierungsdatei referenziert werden. Ein Beispiel 
einer solchen Regelpaket-Spezif izierungsdatei ist in Anlage 2 
angefiihrt. Im Einleitungsabschnitt der Datei ist der Verweis 

30 auf die Sof twarekomponente ersichtlich; die Verweise „install", 
„uninstall", „policies_true" und „policies_f alse" zeigen auf 
die vier Routinen 4, 4', 5 bzw. 5'. 

Die Auswertung des Frameworks FW und Abarbeitung der Re- 
gelpakete RP auf dem Benutzerrechner 2 wird mit Hilfe eines 

35 Klientprogramms KP durchgef uhrt , welches die beschriebene Abar- 
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beitung der Liste L in einem Prozeft P durchfiihrt (Fig. 2) . Zu 
diesem Zweck enthalt das Klientprogramm KP einen Speicher S zur 
lokalen Speicherung einer Kopie des Frameworks FW, welcher auch 
fur die Weiterverteilung (Replikation) des Frameworks FW an an- 
5 dere Benutzerrechner 2 verwendet werden kann. 

Das Klientprogramm KP verfugt ferner liber eine lokale Da- 
tenbank DB, welche zwei Listen 7, 8 fuhrt, deren Verwendung in 
den Fig. 7 und 8 ausf iihrlicher gezeigt ist. Die erste Liste 7 
enthalt einen Eintrag fur jedes Regelpaket RP, dessen Installa- 

10 tionsroutine 4 erfolgreich durchlaufen wurde . Die zweite Liste 
8 enthalt einen Eintrag fiir jedes Regelpaket RP, dessen Konfi- 
gurationsroutine 5 erfolgreich durchlaufen wurde. Damit verfugt 
das Klientprogramm KP uber eine Aufstellung aller auf dem Be- 
nutzerrechner 2 erfolgreich installierten und konf igurierten 

15 Sof twarekomponenten SW, welche bei der Abarbeitung der Regelpa- 
kete RP auch dazu verwendet werden kann, Doppelauf ruf e oder 
endlose Rekursionen usw. zu erkennen und zu vermeiden. Dariiber 
hinaus ist die lokale Datenbank DB auch nutzlich, um obsolete 
oder veraltete Sof twarekomponenten zu erkennen und zu entfer- 

20 nen, wie im Rahmen des Flufldiagramms von Fig. 6 noch ausfiihr- 
lich erlautert wird. 

Fig. 6 zeigt ein beispielhaf tes FluJJdiagramm fiir das 
Klientprogramm KP. Nach einer Initialisierung im Block 9 werden 
im Block 10 alle in der Liste L des Frameworks FW angefiihrten 

25 Regelpakete RP abgearbeitet, und zwar durch Aufrufen ihrer In- 
stallationsroutinen 4. Es versteht sich, da£ dabei die Regelpa- 
kete RP, wenn sie mittels der Detektoren DET die Voraussetzung 
der Anwesenheit oder Abwesenheit anderer Regelpakete RP fest- 
stellen, jeweils in diese anderen Regelpakete rekursieren, wie 

30 bereits erlautert. 

Nachdem im Block 10 alle Installationsroutinen 4 abgear- 
beitet und damit alle erf orderlichen Sof twarekomponenten BS1, 
A, B, . . auf dem Benutzerrechner 2 installiert worden sind, geht 
das Klientprogramm KP bzw. sein ProzeJi P zum Block 11 uber, in 

35 welchem die Konf iguration der Sof twarepakete in einem zweiten 
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Durchlauf durch die Liste L erfolgt. Im Block 11 werden wieder 
die in der Liste L angefuhrten Regelpakete RP abgearbeitet , 
diesmal unter Aufrufen ihrer Konf igurationsroutine 5. Falls er- 
forderlich, konnen die Regelpakete RP wieder in weitere Regel- 
5 pakete rekursieren, wie bereits erortert. 

Dadurch, daft im Block 10 zunachst eine vollstandige In- 
stallation aller erf orderlichen Softwarekomponenten erfolgt, 
wird gewahrleistet, daft das Konf igurieren im Block 11 von einem 
definierten Systemzustand ausgeht, was in vielen Fallen eine 

10 korrekte Konf iguration erst ermoglicht. 

Die weiteren in Fig. 6 gezeigten Blocke 12 und 13 des Ver- 
fahrens bzw. des Klientprogramms KP sind optional und dienen 
der Beseitigung obsoleter oder veralteter Softwarekomponenten 
vom Benutzerrechner 2. 

15 Wie bereits erwahnt, sind Regelpakete RP fur obsolete oder 

veraltete Softwarekomponenten nicht mehr im Framework FW ent- 
halten, konnen allerdings auf einem Benutzerrechner 2 noch er- 
forderlich sein, beispielsweise wegen veralteter Hardwareaus- 
stattung. Das Klientprogramm KP vergleicht daher die im Frame- 

20 work FW enthaltenen Regelpakete RP mit den in den Listen 7 und 
8 der lokalen Datenbank DB eingetragenen Regelpaketen RP und 
versetzt jene Regelpakete RP, welche im Framework FW nicht mehr 
aufscheinen, in einen inaktiven Zustand, z.B. durch ein ent- 
sprechendes Flag in den Listen 7 und 8 oder im Regelpaket RP 

25 selbst. Im inaktiven Zustand ist ein Regelpaket RP nur mehr an- 
hand seiner Deinstallationsroutine 4' oder seiner Dekonf igura- 
tionsroutine 5' aufrufbar. 

Im Block 12 werden alle inaktiven Regelpakete RP anhand 
ihrer Dekonf igurationsroutinen 5' aufgerufen. Im anschlieftenden 

30 Block 13 erfolgt ein erneuter Durchgang anhand ihrer Deinstal- 
lationsroutinen 4' . 

Wie bereits erortert, pruft dabei jede Deinstallations- 
oder Dekonf igurationsroutine (oder auch der Prozefi P) , ob sie 
auf ihr „Ziel", den Benutzerrechner 2, anwendbar ist und nur 

35 dann, wenn dies moglich ist (z.B. Ausbau einer veralteten Hard- 
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ware), wird sie ausgefuhrt. Bei der Dekonf iguration bzw. Dein- 
stallation tragt sie sich auch jeweils wieder aus der Liste 7 
bzw. 8 der lokalen Datenbank DB aus. 

Dadurch wird bei jedem Durchlauf des Klientprogramms KP 
5 gleichsam ein Reinigungsdurchlauf ausgefuhrt, der veraltete 
oder obsolete Sof twarekomponenten und deren Regelpakete besei- 
tigt . 

Im Block 14 des Flufidiagramms von Fig. 6 werden Abschlufi- 
prozesse durchgefiihrt und das Klientprogramm KP beendet. 

10 Das Ausfiihren des Klientprogramms KP auf dem Benutzerrech- 

ner 2 kann auf vielerlei Arten angestoJJen werden. Fig. 9 zeigt 
einige mogliche Varianten. Dem Abarbeitungsprozefi P des Klient- 
programms KP ist hier ein Ereignismanager 15 vorgeschaltet, 
welcher sowohl lokale Ereignisse auf dem Benutzerrechner 2 als 

15 auch entfernte Ereignisse z.B. auf den Wartungsarbeitsplatzen 3 
verarbeiten kann. 

Sinnbildlich sind einige Arten von lokalen Ereignissen 2 
dargestellt, beispielsweise Benutzerereignisse 16 wie die Beta- 
tigung einer entsprechenden Taste, Systemereignisse 17 wie das 

20 Erkennen eines Systemstarts oder -stops, einer Benutzeran- oder 
-abmeldung, einer Netzwerkan- oder -abmeldung, eines Programm- 
starts oder -endes usw. , Hardwareereignisse 18 wie das An- oder 
AbschlieBen einer Hardwareausstattung, oder vom Systemadmini- 
strator definierte lokale Ereignisse 19. Es ist aber auch mog- 

25 lich, daB das Klientprogramm KP durch entfernte Ereignisse aus- 
gelost wird, beispielsweise durch aktives Senden eines Trigger- 
befehls von einer Wartungsarbeitsstation 3 her, oder durch 
„passives" Abholen eines Auslosebef ehls von einer Netzwerkres- 
source RESi, z.B. im Zuge einer Netzwerkanmeldung oder zu vor- 

30 gegebenen Tageszeiten. 

Die genannten Ereignisse konnen auch direkt die Ausfiihrung 
bestimmter Regelpakete RP oder Routinen 4, 4', 5, 5' auslosen, 
und zwar iiber deren Ausloseverweise TRIG (siehe Fig. 4). Der 
Ereignismanager 15 des Klientprogramms KP kann direkt die iiber 

35 die Ausloseverweise TRIG zugeordneten Regelpakete oder Routinen 
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aufrufen, Oder uber die Listen 7, 8 der lokalen Datenbank DB, 
in welche die Regelpakete RP ihre Ausloseverweise TRIG einge- 
tragen haben. Auch ist es moglich, nach einem Auslosen des Er- 
eignismanagers 15 bereits im Block 9 des Klientprogramms KP je- 
5 ne Regelpakete - entsprechend ihren Ausloseverweisen TRIG - 
vorzuselektieren, welche der Ereignisauslosung des Ereignisma- 
nagers 15 entsprechen, und anschlieJiend das Klientprogramm 15 
nur fur diese vorselektierten Regelpakete RP zu durchlaufen. 

Eine andere Moglichkeit ist es, die Ausloseverweise TRIG 

10 in den Regelpaketen RP als „Filter" fur die Abarbeitung der Re- 
gelpakete im Zuge einer ereignisgesteuerten Ausfuhrung des 
Klientprogramms KP zu verwenden: Wenn ein Regelpaket zumindest 
einen Ausloseverweis TRIG enthalt, wird es bei einem Aufruf 
durch das Klientprogramm KP nur dann ausgeftihrt, wenn auch sein 

15 Ausloseverweis TRIG diesem Ereignis entspricht- 

Fig. 10 zeigt ein Implementierungsbeispiel des Klientpro- 
gramms KP im Rahmen eines Betriebssystems eines Benutzerrech- 
ners 2, welches geschutzte Bereiche ( „Kontexte x> ) fur einzelne 
Prozesse bereitstellt, beispielsweise urn Benutzerprozesse von 

20 Systemprozessen zu isolieren und dadurch die Betriebsstabilitat 
zu verbessern. Da die Installation und Konf iguration von Soft- 
warekomponenten haufig kontextiibergreif ende Berechtigungen er- 
fordert, wird hier der Abarbeitungsprozeft P in mehrere in ge- 
schutzten Systembereichen ^Admin^, „User M und ^System" ablau- 

25 fende Ausfuhrungsmaschinen P if P 2 und P 3 unterteilt. 

Fur jede systemmodif izierende Komponente des Verfahrens, 
beispielsweise die Routinen der Regelpakete, kann ein Transak- 
tionssystem implementiert werden, welches einen vollstandigen 
Rollback der Systemkonf iguration ermoglicht, falls die Instal- 

30 lation, Deinstallation, Konf iguration oder Dekonf iguration ei- 
ner Sof twarekomponente f ehlschlagt . 

Die Erfindung ist nicht auf die dargestellten Ausfiihrungs- 
formen beschrankt, sondern umfalit alle Varianten und Modifika- 
tionen, die in den Rahmen der angeschlossenen Anspriiche fallen. 

35 
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ANLAGE 1 

[sml::header] 
smlversion=3.0.0 
encoding=iso-8859-l 
type=dsf 

objectid=3 -A 1 1 - 1 00 A-57F0-1 0OOC00000 1 -0-0 
sqn=3 -FFFF- 1 00 A-57F0-25-0-0 
name=Microsoft Office XP Premium Edition 

[dsf::query_exist] 

/* detect Office 10.0 components */ 
if.reg.keyexist condition:true,- 

>reghive=HKEY_LOCAL_MACHINE,regpam=SOFTWARE\N^ 
{ 

do.reg.setkey regkeyhan- 
dlerhRegislry^eghive^HKEY^LOCALJVLACHINE 
oot,option=OPEN, 

if.sys.handleisvalid conditionrtrue regkeyhandle:hRegistry, 

{ 

;detect WinWord 

;first lefs see if the required file exists 
if.file.exist condition:false,-> 
.->filepam=<! -getreg. value regkeyh^ 

{ 

do.sys.exit->level=section^eUimvalue=tfalse, 

} 

;second lefs check the files required property 
if.file.matchversionproperty condition:false,-> 
.->filepaft=<!-get.reg. value regkeyhandle:^ 
.->propertyname=fileversion 5 versionproperty type:eq,=10.*, 

{ 

do.sys.exit^level^ectionjTeturnvalueHralse, 

} 

do.sys.closehandleregkeyhandlerhRegistry, 

} 

} 

[dsf: :query_acti ve] 

/* dedect if Office 10.0 WinWord component is running */ 
if reg.keyexist condition rtrue,- 

>reghi ve=HKEY JLOCAL_MACHINE 0 .0, 

{ 

do.reg.setkey regkeyhan- 
dle:hRegistry,reghive=HKEY 
oot,option=OPEN, 

if.sys.handleisvalid conditionrtrue regkeyhandle:hRegistry 9 

{ 

;dedect WinWord 

if.process.exist condition: false r >processname= WIN WORD.EXE, module=<!-getreg. value regkeyhan- 
dle :hRegistiy ,->regentry=Path 5 - ! > WINWORD .EXE, 

{ 

caU.sys.exit->level^ection,returnvalue=false, 

} 

call.sys.closehandle regkeyhandlerhRegistry, 
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ANLAGE2 

[sml::header] 
smlversion=3 .0.0 
encoding=iso-8859-l 
type=psf 

objectid=3-3Fl -100A-57F0-1 000C00000 1 -0-0 
sqn=3-FFFF-l OOA-57FO-2-0-0 
name=Microsoft Office XP Premium 

[psf::definition] 

packagename->text=Microsoft Office XP, 

packagedescription->text=The Microsoft Office XP Premium Suite, 
packagecompany->text=Microsoft, 

packagecopyright->text=Copyright© Microsoft Corporation 1985-2001. All rights reserved., 
packageproductversion->versionnumber=l 0.0, 
packagedate->text=2002-0 1-01, 

[sml::system] 

transactioncontext->coiitexrr=package, 

securitycontext->context=ADM, 

oscontext->context=Win32, 

[sml::ossupport] 

\vindowssys->platform==x86,os==nt,osversion type:= =5.0,sp type:>=,=3, 
windowssys->platform=x86,os : =nt,osversion type:=, =5. 1 ,sp type:>«l, 
vraesys->platform^86,wmeversion r^ 

[psf::detectself] 

detectsoftware->obj ectid=3-A 11-1 00 A-57F0- 1 OOOCOOO00 1 -0-0, 

[sml: :displaysupport] 
display->show= 1 , 

displayheader->text=Microsoft Office XP, 
displaytext->text=Manages Microsoft Office XP..., 

[psf: .-archive] 

archivepolicies->archive=l ^verride^l , 
archi veuninstall->archi ve=l , 

[psf::installoptions] 
rollbackonerror->roilback=l , 
installevents->event=ALL, 
ovvnnersonly->restrict=0 9 

[psf::dedecttargets] 

if.group.accountismember->groupname groupformat.default, type:eq,=officexp, 
tpsf::install] 

installj obid->objectid=3 -411-1 00 A-57F0- 1 OO0C00000 1 -0-0, 
[psf::uniristall] 

urjmstalljobid->objectid=3-441-100A-57F0-1000C000001-0-0, 
[psf::policies_true] 

policyid->objectid=3-47 1 -1 00 A-57F0- 1 000C00000 1 -0-0, 
[psf: :policies_false] 

policyid->objectid=3-47 1 - 1 00 A-57F0- 1 000C00QQ02-O-O 
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Patentanspriiche : 

1- Verfahren zur autornatischen Installation und Konfigu- 
ration von Sof twarekomponenten (SW) in einem Computernetzwerk 
5 (1), das eine Vielzahl von Benutzerrechnern (2) und zumindest 
eine Netzwerkressource (RES) von installierbaren Sof twarekom- 
ponenten umfaftt, gekennzeichnet durch die Schritte: 

a) Bereitstellen eines Frameworks (FW) auf der Netzwerk- 
ressource (RES) , welches ein Regelpaket (RP) fur jede der in- 

10 stallierbaren Sof twarekomponenten (SW) der Netzwerkressource 
(RES) und eine Liste (L) abzuarbeitender Regelpakete (RP) um- 
fafit, nicht jedoch die Sof twarekomponenten (SW) selbst, 

wobei zumindest eines der Regelpakete (RP) eine Routine 
(4) zum Laden seiner Sof twarekomponente (SW) von der Netzwerk- 

15 ressource (RES) her und Installieren auf einem Benutzerrechner 
(2) und zumindest dieses oder eines der anderen Regelpakete 
(RP) eine Routine (5) zum Konf igurieren seiner auf einem Benut- 
zerrechner installierten Sof twarekomponente (SW) umfafrt, 

b) ttbertragen des gesamten Frameworks (FW) an einen Be- 
20 nutzerrechner (2); und 

c) Abarbeiten der Liste (L) abzuarbeitender Regelpakete 
(RP) mit Installationsroutinen (4) auf dem Benutzerrechner (2) 
unter Aufrufen ihrer Installationsroutinen (4), und nochmaliges 
Abarbeiten der Liste (L) abzuarbeitender Regelpakete mit Konfi- 

25 gurationsroutinen (5) auf dem Benutzerrechner (2) unter Aufru- 
fen ihrer Konf igurationsroutinen (5) f 

wobei zumindest Schritt c) durch ein lokales Ereignis (16- 
19) auf dem jeweiligen Benutzerrechner (2) ausgelost wird. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, 

30 daS Schritt c) durch einen Systemstart oder -stop, ein System- 
sperren oder -freigeben, eine Benutzeran- oder -abmeldung, eine 
Netzwerkan- oder -abmeldung, einen Programmstart oder -ende, 
das An- oder Abschlieflen einer Hardwareausstattung oder durch 
einen Zeitgeber ausgelost wird. 
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3. Verfahren nach Anspruch 1 oder 2, bei welchem die er- 
folgreiche Installation einer Sof twarekomponente auf einem Be- 
nutzerrechner die An- Oder Abwesenheit, Konf iguration oder De- 
konf iguration einer anderen Sof twarekomponente als Vorausset- 

5 zung haben kann, dadurch gekennzeichnet , 

daft im Schritt a) das Framework (FW) einen Detektor (DET) 
fur jede mogliche Voraussetzung und zumindest eines der Regel- 
pakete (RP) eine Routine (4') zum Deinstallieren seiner Soft- 
warekomponente von einem Benutzerrechner (2) und zumindest die- 
10 ses oder eines der anderen Regelpakete (RP) eine Routine (5') 
zum Ruckgangigmachen (Dekonf igurieren) der Konf iguration seiner 
Sof twarekomponente (SW) auf einem Benutzerrechner (2) umfaftt, 
und 

daft im Schritt c) , wenn im Zuge eines Regelpakets (RP) 
15 mittels eines Detektors (DET) festgestellt wird, daft die An- 
oder Abwesenheit, Konf iguration oder Dekonf iguration einer an- 
deren Sof twarekomponente (SW) erforderlich ist, die In- 
stallations-, Deinstallations-, Konf igurations- oder Dekonfigu- 
rationsroutine (4, 4' , 5, 5') des dieser anderen Sof twarekompo- 
20 nente (SW) zugeordneten Regelpakets (RP) aufgerufen wird. 

4. Verfahren nach einem der Anspriiche 1 bis 3, dadurch 
gekennzeichnet, daft das Framework (FW) auch Detektoren (DETHW, 
DETBS1) fur die Hardware- oder Betriebssystemausstattung eines 
Benutzerrechners (2) umfaftt und im Zuge einer Routine (4, 4', 

25 5, 5' ) mittels eines solchen Detektors uberpruft wird, ob der 
Benutzerrechner (2) fur die jeweilige Installation, Deinstalla- 
tion, Konf iguration oder Dekonf iguration der Sof twarekomponente 
(SW) geeignet ist. 

5. Verfahren nach einem der Anspriiche 1 bis 4, dadurch 
30 gekennzeichnet, daft im Zuge einer Routine (4, 4', 5, 5' ) vorab 

gepruft wird, ob die jeweilige Installation, Deinstallation, 
Konf iguration oder Dekonf iguration der Sof twarekomponente (SW) 
auf dem Benutzerrechner (2) bereits erfolgt ist und, wenn ja, 
die Routine sofort beendet wird. 
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6. Verfahren nach einem der Anspriiche 1 bis 5, dadurch 
gekennzeichnet, daft Schritt b) und/oder Schritt c) auch durch 
ein entferntes Ereignis auf der Netzwerkressource ausgelost 
wird, bevorzugt das Aussenden einer Gruppen- oder Broad- 

5 castnachricht . 

7. Regelpaket, das auf einem Betriebssystem eines Benut- 
zerrechners (2) ausfuhrbar 1st, zur automatischen Installation 
und Konf iguration von Sof twarekomponenten (SW) , die auf einer 
Netzwerkressource (RES) verfugbar sind/ auf dem Benutzerrechner 

10 (2) , dadurch gekennzeichnet , daft das Regelpaket (RP) einen Ver- 
weis (RES A ) auf eine Softwarekomponente auf der Netzwerkres- 
source (RES) und zumindest eine der folgenden vier Routinen um- 
fafit: eine Routine (4) zum Installieren dieser Softwarekompo- 
nente (SW) auf dem Benutzerrechner (2) , eine Routine (4') zum 

15 Deinstallieren dieser Softwarekomponente (SW) vom Benutzerrech- 
ner (2), eine Routine (5) zum Konf igurieren dieser auf dem Be- 
nutzerrechner (2) installierten Softwarekomponente (SW) , und 
eine Routine (5' ) zum Ruckgangigmachen (Dekonf igurieren) der 
Konf iguration dieser auf dem Benutzerrechner (2) installierten 

20 Softwarekomponente (SW), wobei jede Routine (4, 4', 5, 5' ) , 
wenn sie das Erfordernis der An- oder Abwesenheit einer anderen 
Softwarekomponente • (SW) feststellt, zur Installations- bzw. 
Deinstallationsroutine (4, 4') eines dieser anderen Software- 
komponente (SW) zugeordneten anderen Regelpakets ■ (RP) ver- 

25 zweigt. 

8. Regelpaket nach Anspruch 7, dadurch gekennzeichnet, 
daft es einen Verweis (DEThw/ DET B si) au f eine bestimmte Hard- 
ware- und/oder Betriebssystemausstattung eines Benutzerrechners 
(2) umfaBt und anhand dieses Verweises liberprtift, ob der Benut- 

30 zerrechner (2) fur die jeweilige Installation, Deinstallation, 
Konf iguration oder Dekonf iguration der Softwarekomponente (SW) 
geeignet ist. 

9. Regelpaket nach Anspruch 7 oder 8, dadurch gekenn- 
zeichnet, daJi es iiberpriift, ob die jeweilige Installation, 

35 Deinstallation, Konf iguration oder Dekonf iguration der Soft- 
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warekomponente (SW) auf dem Benutzerrechner (2) bereits erfolgt 
ist und, wenn ja, seine Ausfiihrung beendet. 

10. Regelpaket nach einem der Anspruche 7 bis 9, dadurch 
gekennzeichnet, daft es mindestens einen Ausloseverweis (TRIG) 

5 auf ein lokales Ereignis (16-19) auf dem Benutzerrechner (2) 
enthalt, wobei der Ausloseverweis (TRIG) diesem Ereignis zumin- 
dest eine der Routinen (4, 4', 5, 5') des Regelpakets zuordnet. 

11. Regelpaket nach einem der Anspruche 7 bis 10, dadurch 
gekennzeichnet, daft es ferner mindestens einen Ausloseverweis 

10 (TRIG) auf ein entferntes Ereignis auf der Netzwerkressource 
enthalt, wobei der Ausloseverweis (TRIG) diesem Ereignis zumin- 
dest eine der Routinen (4, 4', 5, 5') des Regelpakets zuordnet. 

12. Regelpaket nach einem der Anspriiche 7 bis 11, dadurch 
gekennzeichnet , daft es in einen inaktiven Zustand versetzbar 

15 ist, in welchem nur seine Deinstallations- und Dekonf igurati- 
onsroutinen (4', 5') aufrufbar sind. 

13. Computer, der mit zumindest einem Regelpaket nach ei- 
nem der Anspruche 7 bis 12 programmiert ist. 

14. Framework, das auf einer Netzwerkressource (RES) in 
20 einem Computernetzwerk (1) fur eine Vielzahl von Benut zerrech- 

nern (2) bereitstellbar ist, zur automatischen Installation und 
Konf iguration von auf der Netzwerkressource (RES) verfiigbaren 
Sof twarekomponenten (SW) auf den Benut zerrechnern (2), wobei 
die erfolgreiche Installation einer Sof twarekomponente (SW) die 

25 An- oder Abwesenheit einer anderen Sof twarekomponente (SW) vor- 
aussetzen kann, dadurch gekennzeichnet, daft das Framework (FW) 
einen Satz von Regelpaketen (RP) nach einem der Anspriiche 7 bis 
12, einen Satz von Detektoren (DET) fur jede mogliche Voraus- 
setzung, und eine Liste (L) von auf den Benutzerrechnern (2) 

30 abzuarbeitenden Regelpaketen (RP) umfaftt. 

15. Framework nach Anspruch 14 in Verbindung mit einem 
Regelpaket nach Anspruch 8, dadurch gekennzeichnet, daft das 
Framework (FW) auch Detektoren (DETHW, DETBS1) fur die Hard- 
ware- oder Betriebssystemausstattung eines Benut zerrechners (2) 
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umfalit und den Regelpaketen (RP) fur die genannte Oberpriifung 
zur Verfiigung stellt. 

16. Computer , der mit einem Framework nach Anspruch 14 
oder 15 programmiert ist. 
5 17. Maschinenlesbarer Datentrager, der mit einem Framework 

nach Anspruch 14 oder 15 programmiert ist. 

18. Klientprogramm, das auf einem Benutzerrechner (2) 
ausfiihrbar ist, zur automatischen Installation und Konfigura- 
tion von Sof twarekomponenten (SW) , die auf einer Netzwerkres- 

10 source (RES) verfugbar sind, auf dem Benutzerrechner (2), da- 
durch gekennzeichnet, dali es ein Framework (FW) nach Anspruch 
14 oder 15 empfangt und speichert, in einem ersten Durchgang 
die Liste (L) abzuarbeitender Regelpakete (RP) unter Aufrufen 
ihrer Installationsroutinen (4) und in einem zweiten Durchgang 

15 die Liste (L) abzuarbeitender Regelpakete (RP) unter Aufrufen 
ihrer Konf igurationsroutinen (5) abarbeitet. 

19. Klientprogramm nach Anspruch 18, dadurch gekennzeich- 
net, daft es eine lokale Datenbank (DB) aufweist, welche eine 
Liste (7) von Regelpaketen (RP) mit erfolgreich durchlauf enen 

20 Installationsroutinen (4) und eine Liste (8) von Regelpaketen 
(RP) mit erfolgreich durchlauf enen Konf igurationsroutinen (5) 
enthalt . 

20. Klientprogramm nach Anspruch 19, dadurch gekennzeich- 
net, daJi es die in den Listen (7, 8) eingetragenen Regelpakete 

25 (RP) mit den im Framework (FW) enthaltenen Regelpaketen (RP) 
vergleicht und fur jene Regelpakete (RP), welche im Framework 
(FW) nicht aufscheinen, in einem ersten Durchgang deren Dekon- 
f igurationsroutinen (5') und in einem zweiten Durchgang deren 
Deinstallationsroutinen (4' ) abarbeitet. 

30 21. Klientprogramm nach einem der Anspriiche 18 bis 20 in 

Verbindung mit einem Regelpaket nach Anspruch 10, dadurch ge- 
kennzeichnet , daii es das Auftreten eines lokalen Ereignisses 
(16-19) auf dem Benutzerrechner (2), bevorzugt eines System- 
starts oder -stops, eines Systemsperrens oder -freigebens, ei- 

35 ner Benutzeran- oder -abmeldung, einer Netzwerkan- oder 
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-abme ldung, eines Programmstarts oder -endes, des An- oder Ab- 
schliefcens einer Hardwareausstattung, oder des Ansprechens ei- 
nes Zeitgebers f uberwacht und die diesem Ereignis iiber den Aus- 
loseverweis (TRIG) zugeordnete Routine (4, 4' , 5, 5') des ent- 
5 sprechenden Regelpakets (RP) aufruft. 

22. Klientprogramm nach einem der Anspriiche 18 bis 20 in 
Verbindung mit einem Regelpaket nach Anspruch 11, dadurch ge- 
kennzeichnet, dafc es ferner das Auftreten eines entfernten Er- 
eignisses auf der Netzwerkressource, bevorzugt das Aussenden 

10 einer Gruppen- oder Broadcastnachricht , uberwacht und die die- 
sem Ereignis iiber den Ausloseverweis (TRIG) zugeordnete Routine 
(4, 4' , 5, 5'). des entsprechenden Regelpakets (RP) aufruft. 

23. Klientprogramm nach einem der Anspriiche 18 bis 22, 
dadurch gekennzeichnet , dafi es ein Transaktionssystem fur jede 

15 systemmodif izierende Komponente, insbesondere fur die Regelpa- 
kete (RP) , aufweist. 

24. Computer, der mit einem Klientprogramm nach einem 
der Anspriiche 18 bis 23 programmiert ist. 

25. Computerprogramm, implementierend ein Verfahren nach 
20 einem der Anspriiche 1 bis 6. 
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Fig. 2 
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Fig. 3 
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Fig. 7 
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Fig. 10 
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